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Specification u{ the Unified User-Lev el Protocol 


This document represent'd the results of various inputs, both in 
response to RFC -Vol and from otner sources. The dominant other 
sojrce was my frienoiy neignborhooa Principal Investigator, who 
folu mo that The AKPA office is ojite interested in the 
specification of a Network-wiae user interface. As Just such a 
fnuivj was the underlying motivation of tne tentative proposal for 
a unified user-level protocol (UULP)» it seemed appropriate to 
cone up with the following. it is being distributed in draft 
form to the atTendeos of the Resource Snaring Workshop, with the 
expressed understanding that many details are subject to change. 


£sai£x± 


The UULP is initially to oe a negotiated option, in the sense of 
tno Telnet Protocol. When the option is enaoled, the Server Host 
wilI furnish a command environment wnich supports the conventions 
and conmanas discussed herein. Any optional commands which are 
not supported by a particular Server are to De responded to by 
the following message.’ "Not implemented} commpn pri n me . “, where 
com in a nan a me- is the name of the command which was requested. Note 
that throughout This document, all literals must be sent exactly 
as specified, so as to allow for the possibility of Servers’ 
oeing driven by users’ programs ("automata", or “command macros") 
in addition to "live ' 4 users. 


The intent of the p-otocol is to furnish a “common command 
suosef" which will allow users to use various Servers over the 
Network without being constrained to learn tne various "command 
languages" which aoound. That is* in the spirit of the Telnet 
Protocol's "common intermediate representation" approach to 
solving the local-conventions problem, the UULP takes the view 
that is is far bette- for the user to be able to say "who" on any 
Host in oroer to lea’n wno else is logged in than to have to 
remember whether on this particular Host it*s "systat", "s 
•wnofc", "lisff tty", or even "who". In other words, functions 
which ore in some sense generic among the Servers are to be 
invoked in a common fashion. Where the command aspects of other 
user-I eve I protocols are clearly generic* they too are to be 
invoked via tne UULP. Note that only minimal assumptions are 
made about a Server's implementation. In general, the goal is to 
allow tne UUcP to "f’onf end" onto local implementations. 


To exit from the JULP environment, the UULP command is "local" 
(aooreviationi "Ioc"l see also the discussion of Case, below). 
Note tnat ill commands terminate in Telnet "Newline" (currently 
cr-If), unless altered oy the "eol" command (below); internal 
separator is space (plank). There are two reasons for 
introducing a mechanism other than the apparently natural one of 
sinply ue-negotiuting tne optionf First, it is bound to be more 
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convanijnt for the us or to type a command than to escape to his 
User To I net program to cause the option disabling. SeconJi it is 
hop aa t n a t eventually the UULP will oe Ie yislated to be the 
default environment encountered by any Network login, in which 
case the natural w^y to enter the Server's "native" command 
environment wouId be oy UULP c0mmanJ• 

Note: all UU L P commands discussed herein are listed in 
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upper-case-on Iy terninals has long been a , thorny one. .Some 
Servers have no problems in such circumstances, as they operate 
internally in all upoer-case or all lower-case ana merely map all 
inout appropriateIy. Other Servers, however, attach the normal 
linguisTic significance to case. (E.g., Smith's name is "Smith" 
-- not “SMITH", and not "smith".) To minimize superfluous 
processing for those Servers which are indifferent to case, ail 
UULP commands are to do recognized as such whether they arrive as 
all upper-case or all lower-case. (They will be shown here as 
all lower merely for typing convenience.) Note that arbitrarily 
mixed case is not recognized, as it is an unwarranted assumption 
about local implementation to suppose that input will necessarily 
be case-mapped. 

Any Server wnich aoes distinguish between upper- and lowei—case 
in commands' arguments (s.K.a. parameters) must furnish a UULP 
'’map" command as specified in Appendix 2 in order to support 
logins from upper-case-only terminals attachec to User Hosts 
which either do not support the Telnet Protocol's dictum that all 
12d ASCII cooes must oe generable, or support it awkwardly. This 
seems a simpler and oreferaDle solution than the alternative of 
legislating that uoper-csse Network-wide personal identifiers 
(and perhaps even Network Virtual Path Names) be pre-conditions 
to a usable common command suoset. (As noted below, fhese latter 
concepts wall fit xn smoothly when they are agreed upon. The 
point nere, thougn, is that we need not deprive ourselves of the 
benefits of a UULP until they are agreed upon.) The "map" 
command should not bo a problem, for the only Host which is known 
to be a respecter of cases already has one. 

U se r LL^e s 

As implied above, tha various Servers have tneir various ways of 
expressing users' mames. Clearly, tha principle of economy of 
memory dictates that there should be a common intermediate 
reoresenfation of names in and for the Network. It is prooably 
also clear tout this represent ation will be based upon the 
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Network Inf ormuTioi Center's “NIC Id's". Howovort it i 3 i 

un f or t jiUi t c I y amply clear tlv.n an acceptable mechanism for j 

securing up-ro-uatu information cannot be legislated hoi'e — 1 

much I ess a mechanism for securely updating the implied data base. 

There f ore , ot this stage it seems to be the sensible thing to 1 

specify only The UUL 3 sy.nt.ax for conveying to the Server the fact 
thot it is to treat a user name as o Network-wide name rather 
than os a local name, and let the supporting mechanisms evolve as 
t n e y m a / , 

The prefacing of a name with an asterisk ("'“') denotes a 
Ne t wor^-w i uc name. (Such names may be either all upper-case or 
all lowir-case, as with IHJLP commands' names.) The name "♦free" 
is explicitly reserved to meiin that (in the context of logging 
in) a login is ac-siraa on a supported or sampling account, if 
suen an accojnt is availaoie. The response if no such account is 
avail ao It is to be "Invalid idents ♦free," VI hen Network-wide 
names are generally avuilaole Servers will either map them into 
local no tries or cause tnem to oe registered as local names as they 
prefer. The point is that a Network-wide name will be "made to 
work" oy the Server in the context of the UULP. 

C n a r a c t e r s and S i on a I s 

Another area in whicn the facts of life must outweigh the letter 
of the Telnet Protocol if the user's convenience is to be served 
is th31 of "erase" and "kiI I" characters. It is possible that 
User Tilnets will uniformly facilitate the transmission of the 
Telnet control coaes for generic character erase and generic line 
kill. It is certain, however, tnat User Telnets will differ 
and users will, if they use more than one User Telnet, be again 
placed in the uncomfortable position of having to develop too 
many sets of reflexes. Therefore, the UULP will optionally 
support the following commands: “erase £h^c" (abbreviation: "er") 
and "Kill cha r", whe'e chaQ is o printable ASCII character (to 
avoid possible conflicts with "control characters" which are 
recognidau in the innermost areas of particular operating 
systems). These commands are supplements to the- related Telnet 
control codes, and have tne same meanings. The point here is 
tnsl if may be far more convenient for a user to be able to say 
"erase ft" and yet the "ft" to be recognized as the erase character 
by tno Server than for trie user to get his User Telnet to send 
the FulneT equivalent. The commands are designated as options, I 
oecause they may lead to severe implementation problems on some 
Servers, and because the eauivalent functions ao, after all, 
exist m Telnet. 

Note: the erasing is assumed to be performed "as early as 
possible". That is, the sequence "erase x" “erase x" snould 
come out equivalent to "erase x" "erase" — the second 
invocation resulting in the erasing of the space in the ' 
conmanu line. Presumably, this is a sufficiently uncommon 
path that anomalous results would bo toleraled oy the user 
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cjJiBuruty, but Tno intent ought to ue clear. 

The Telnet ‘'i,ynch" and "oresk" mecnanisms are, by tneir very 
noture, peat left to Telnet. £nd of line, however, might well be 
a different story. Therefore, us a potential convenience* the 
UUlP optionally supports "eol an.eE:" to ask the Server to treat 
C.hi£L as the oncl of line character thenceforth. To revert to 
Telnet Newline, "eol'* (i.e., no argument, current terminator). 


Pc^mal.-a 

Another aspect in waich Servers vary wniIe being the same is how 
they in Jicote "being at command level". Some output "reacy 
messages"? others, "prompt characters". For the UULP, wnere some 
functions will oe performed ay means of a command's logging in to 
another system, tne ability to specify a known prompt character 
xs extremely aesiraole. The UULP command is "prompt ahnn." 
(aobreviation: "pr"), wnere nnsr is the character which is to be 
sent when the ustr’s process (on the Server) is at command level. 
It is explicitly permitted to prefix £ho.r to a line consisting of 
a “native" prompt o~ ready message. Also, this command is 
explicitly acknowledged to be permissible prior to login. 


Note: "prompt", "col", “erase", and "kill" may all be 

re-invoked with a new value of stme. in order to change the 
relevant setting? alI may oe turned off by invocation with 
no argument. 


koala 

Perhaps the sTicwiest wicket of them all is the attempt to 

specify a generic login, but here we go. The UULP login command 
is "login up er i dent" (abbreviations “in") , where u seri de nt is 
either a locally-acceptable user identifier or a Network-wide 
identifier as discussed aoove. Note that for utility in contexts 
to be discussed later., the I oca I Iy-acceptabIe form must not 
contain spaces. (Again, the only Host known to have problems on 
tnis score is prepared to cope — with a period (".") bet ween 
personal name and project name.) Servers may respond to the 
login attempt with 3'biTrary text (such as a "message of the 

day"), but some line of the response must be one of the 

following: a prompt (as discussed aDove? indicating, in the 
present context, successful login)? "Password:"? or “Invalid 
id-ant: u stCxJlS. Ql. “ when passwords are required, it is the 
Server's ivsponsibility either to send a mask or to successfully 
negotiate the Hide Our Input option. 

Note that "login *froe" is specifically definco to require no 
passwori. (If a "freeloader" has access to a User Telnet and has 
learned of me "♦fret" syntax, it is fruitless to assume that he 
couldn't nave ulso re^d the common password.) If a password must 
oe given, acceptable responses are arbitrary text containing a 
line uo jinnio-j eith':r with a prompt or witn “Login unsuccessful." 
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or m iTn "Account:". in the letter cusei responses to the account 
'mu.it o ■: one of tne former two. If any errors occur during the 
login juguence, user: are to re-try by starting from tne login 
co.iiiunJ. (Inn , it is not requirea to it the Server "remember" 
idents or passwords.) 

It is e<plicit|y uclnow lodged tnut on acceptsDle response to 
“login * f rue" i 2 "c i mi teu jccess only." { f o I I owe q by a pr om p t) • 
This is intended to warn (human) users tout the free account on 
the Survur in question exists only to allow such functions as 
accepting mail and tailing if a particular user happens to be 
logged in. (For oo]actions to "loginless" performance of such 
tasKS, see RF C 491. Note also that notning here says that a 
Server must do anything other than rot urn a prompt in response to 
"login ♦fret" in the event That loginless operation is natural to 
it.) uiven the UU.P login discipline and the "prompt" command* 
it is reasonaoly sfraightforward for a program to login on a free 
account ana perform one of these functions, for if the login 
command succeeded, tne program will "see" a guaranteed prompt 
charac t er. 

To make life simpler for those Hosts which normally have some 
sort of "oaemon" process service mail and the like, a further 
expansion to login is in order. The point here is that some 
Hosts iDcy not know what sort of process to pass an unqualified 
"login *froe" to, whereas they’d be sure what to do with sn 
explicit request to process mail, do a who command, or set up 
console to console communications. Therefore, UULP "login" will 
allow a "control argument" (see below) of either "-mail", "-who", 
or "-concern", and tne respective UULP commanas involved must use 
the respective strings in any login line they transmit. Again, 
nothing is oeing said about what a Server ha.s to do with the 
information, but soma Servers need/want it. 

U , s a g e Inf or mat ion 

Most Servers offer some sort of on-line documentation,' from 
calling sequences of commands to entire users’ manuals. There 
are two sorts of information of interest in the UULP environment: 
"normal" system i n f c - * m a t i on , and information about the particular 
Server’s UULP implementation. To learn how to get descriptions 
of "native" commands, the UULP command is "help -sys" 

( aour avi a 1 1 c.n : Note tnat "-sys" is viewed as a "control 

argument" and as such prefaced by a hyphen ("-") to facilitate 
dialinet ion from other sorts of name (e.g., command names). To 
get a uescription of tne Server’s UJLP implementation, "help 
-uuIp". To get a description of a particular UULP command's 
implementation, "nelo SLomname". To, De reminded of how to use the 
help cornnand, "help". 

Note: as with command names and Network-wide user names, 

control agrumenfs may be either all upptr-case or all 
lower-case. 
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It is s pi c i f i Cci I ly ocKoonl edged tha t “llo peculiarities." is an 
approprio t response to "nelp curnname" if nothing of interest 
noeo t)j said about tha Server's i mp I e me n t u t i on of the UULP 
command x n questio-). (At Tar all, we're sparing users the 
necessity of studying a dozen or so users' manuals; the least 
they cun uo is to read the UULP command list.) Appropriate 
information for less Taciturn Hosts to furnish would be such data 
us I o o j I commons iivokeq (if such oe tne case) ( argument syntax 
(e.g., pathname a os c ri p 7 ion , or name of help file aoout 
pathnames), "To oe implemented.", or even "Not to be 
i mp I ernent cu . " 

"Hi i.1" 

Even though a separate mail protocol is being evolved for general 
purposes, the UULP needs to address this topic as, by virtue of 
being login cased, it allows systems which do access control and 
sender authentication on mail to make these abilities available 
to users within its framework of generic functions. Therefore, 
to read one's mailoox, the UULP command is "reaamail" 
(aobreviation! "rm"). To have "live" input collected and sent to 
a local user, "mail userident"! to a remote user, "mail 
u s a r i d •; q t -at h^tniiue" , wnere The arguments have the "obvious" 
meanings. To send a prev i ous I y-created file, "mail -f f i I e n.n m g 
u serid ent -at h ost name". Several useridents may be furnished; 
the delimiter is space (blank). Similar considerations apply to 
hostnames. If both are lists, they sould be treated pairwise. 
(A more elaborate syntax could be invented to deal with the 
desire to send to several users at a given host and then to other 
users at other hosts, but it seems unnecessary to do so at this 
point, for multiple invocations would get the Job done.) 


The mail command prefaces the message with a line identifying the 
sender (Host and time desirable, but not mandatory). For “live" 
collection, the end of message is indicated by a line consisting 
of only a period (".") followed by the regnant line terminator 
(usually the Telnet Newline, but see also the discussion of the 
eol com,nano). If remote mail is not successfully transmitted, it 
is To be be saved in a local file and that file's name is to be 
output as part of tha failure message. ("Queueing" for later 
transmission is adnired, but not required.) The transmission 
mechanism will follow the general mail protocol. Note that when 
invoked with a "-at" clause, the mail command will send "login 
* f r ee-nail" to the 'emote Host(s), followed by a mail command 
with no "-at" clause. 


A desirable, but not required, embeI Iisnment to "readmai I" wouId 
oe tne accepting of a Host name ("-at h os t na p^e") to cause the 
local Host to go off to tne named Host (via "login *free -mail") 
and check for mail tnere. Several hostnames could, of course, be 
specified. A furthe~ embellishment, which would prooably be 
quite expensive, would oe to accept "-all" as a request to check 
all Hosts (or, perheos, all Hosts known to have a free account 
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.f ci' the purpose) for noil, 

Hic.pci kiii^yais-iiiioo 

The ooili + y tc exchange masso^us Jirc-ctly with other logged in 
users is .apparently .jreoT I y prize a by many users.. Ineratore, 
despite the tuct thar tnere is a sense in wnicn tnis function is 
not Hitnin the purview of the UULP, we will address it, after a 
digress.on. 

Digression! The UULP assumes that there can be 
straighfferwaru "front ends" at Ihe various Servers which 
tnns.lota genc-'ic function calls in 3 common spelling to 
calls for specific, pre-existing "native" functions. In the 
ores of console to console communications, however, this 
premise does not really nold. The problem is that both 
major "native" implementations Known to Ihe author are 
seriously flawed. The TENEX "linK" mechanism is both 
insecure (you've got no business seeing, everything I type 
even if I'm Careless enough to let you) sno inconvenient 
(wny should I be forcea to remember that pesky semi-colon? 
how do I get Dacw into phase after I've forgotten one?). It 
is also likely to be extremely difficult to simulate on 
systems which do not force Network I/O through local TTY 
buffers, even if the user interface were not subject to 
criticism. The Multics "send_message" mechanism, on the 
otner hand, has a more sophisticated design, but is absurdly 
expensive. Therefore, the UULP mechanism to be described 
assumes that, for this function, new local implementations 
will be developed to support it. 

The prerequisites f o- establishing communications are to find out 
if tno user is logged in, and what "address" to use if so. The 
mechanism for gathering tnis information is an expanded "who" 
command. (Note that "wno" is the UULP command to invoke the 
generic wno's logged in function, with no constraints on format 
of reply.) The syntax is “who useni.de rvt -at h ost n ame ", wnere 
botn arguments may ba multiple. If no "-at" clause, then cneck 
local Host only. Response must begin "From hostna me : use rigent:" 
followed ty either an appropriate address (e.g., "11" if local 
"cohco.n" (see oelow) uses TTY numbers and us er i der.t is logged in 
on TTY 11), or "Not logged in." 

As witn moil, a "-all" embellishment might be pleasant. Note 
that tru starch for the specified user(s) -- whether or net 
"-all" is used -- still assumes that a "login Mrea -wno" login 

wilI bu used on the appropriate remote host(s), followed oy "who 

• This is why responses to the expanded who command 

must oe so rigidly specified. Note also that regardless of 

whet nor tne inquiry is made in terms of Network-wide or local 
user name, the response- must oe appropriate for use in "concom". 
Further, if multiple inquiries are made, responses must oe in the 
order received. 




uulp Suva 


p. 3 


, ..ft 

I o en Hi I t con^ok 1 to con oole common icciti oiv; : "concern -on" 
( i' j ^ f' i * u i i.i 1 1 O' k cc ) . to o i a a o i e , condom —off « l) e f o u I t is 
off. To cnT'.r no i j a >j >: - s on -f i n j mode.* concern iilii.f2i.loni. -at 
QO-iiiitni" ("-<-t" clujju is optional). To exit from 

.m: s sa-g e-s on j i n g moco * Type a line consisting of only a ooriod 
(cf. Moil, uuovt) .■ Tito first message sent py concom must be 
prifoCi'J Dy an identifying line, beginning "Front" one containing 
on ojoropriuf i. c. duress to wnich to reply. Tne closing 
period-only line should oe transmitted, so os to allow tne other 
conco m to close os well. Acceptable error response is “Not 
available: iiliiciiieal. " (whicn neither confirms ror denies the 
exist once of ine oorTicuiar user -- a matter of concern on the 
security front). The command must, of course, oo whatever is 
necessary To transmit The messages; i.e., if locally invoked, 
access the local mechanism, and if invokec for remote 
co.nnunica t i ons, access the remote Host's concom command (via 
"login "Mrac -concom"). 

"Good" concom implementations will presumably do an expanded who 
command automatically, so as to spare the user the necessity of 
having to oo it sepa'aTely. Indeed, tne -concom control argument 
to login is defined to imply the ability to do a who as well as a 
concom to cater to this possibility. It is tempting to legislate 
that suen an approach oe the rule, Put the implementation 
implications are not quite clear enouyn to oo so. The implicit 
who snojlj be viewed as a strong nint to impIementers, though. 

£ilje £HJ.£i±ioQ aOl 

For file manipuIatioh commmands, the user could enter the File 
Transfer Protocol environment. However, the FTP user interface 
is constrained by a very nign degree of program-drivabiIity. It 
also I acKs auoreviations and suffers from the lack of mnemonicity 
dictated by limiting command names to four characters. Further, 
some valuable functions (such as causing a file to be typed out) 
are not dealt with. Therefore, various UULP file manipulation 
commands are given ih Appendix 1. They need not be addressed in 
derail nere. Howeve’*, some context would be useful: 

The file manipulation commands assume that al I Servers have so re 
notion roughly corregyonding to "the user's working directory". 
All file names, whether the yet to be invented Network Virtual 
Patnnurnj or the "local" varieTy, arc taken to refer to files in 
this directory unless otherwise indicated. That is, the user 
should not have to tarnish "dskt" or tne like? it is taken as 

given Thut when ne refers to file "x" he means "the fi le named 

'x' in my current working directory" and the Server "knows" what 
that means. 

On tne topic of file creation, matters are rether complicated. 
It is clear thot the aeility to create files in the UULP 

environnem is extremely desirable. It is also clear that using 

mail to a fake adores^ to yet the file created, then renaming the 
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" u i p ui n t mail" file is too b y z an tine to expect users to do . 
b 1 1 ; o r i u n i 1 t I y , it i not c I u.ir exactly wiist the a I t e r n a t i v e i s . 
I ‘ t ' 1 i -• » it’s fairly c I ujp tiut we need a common editor > out it's 
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oroulem 10 noun a to oo a large one. Even if all the relevant 
dyatem programmers could agree, there remains the question of 
whether the intended user population would be willing to pother 
learning a language as complex as TZCO or Q.ED. Therefore an 
optional UULP command to do called "eait" is proposed. Tnis 
oaitor is a line-oriented context editor (no "regular 

expressions", out also no line numbers). It is copiously 

documented in Chapter g or tne Multics Programmers* Manual, 
including un annotated listing of tne (PL/I) source code. A 
simple user's guide may be found in Appendix 3. It's easy to use 
a nJ cniap to implemart. It may also be repugnant to some of the 
System proyrammtrs wno would oe cal lea upon to implement it 
which is why it is optional, until and unless higner authority 
maKes it mandatory. 

iii_Q£s.C, £C.o t0£0j.s 

The nominal initial impetus for proposing a UULP was to allow new 
Network user protocols to be invokable through a common 
mechanism, rather tnan requiring a new responding mechanism to be 
huilt for a new contact socket for each new protocol. Although 
this gojI has been snunted into tne background by the admission 
of me true goal of tne UULP, it has not been dropped completely. 
Therefore, to enter the FTP Server environment, the UULP command 
is "ftp"; to enter tne RJE Server environment, the UULP command 
is "rja". Exit is as per the respective protocols. 

Qln^c. it t >-rs 


Progranning languages are much too big a problem to tackle here. 
However, assuming tnat a user somehow manages to create a source 
Program, he might want soma commonality of spelling in invoking 
thd appropriate compiler, or even tne ooject program. As an 
optional UULP command, then, “call Q2.ms" should invoke ooject 
program name (where tne named program may oe a "native" command 
with agruments specified as ap pr opr i a t e ) . Tne- values "-pll", 
"-basic”, *'-f ortran", "-lisp", etc., should be recognized as 
requesting the invocation of the approoriate language processor 
fto operate on a named source file or 

ifiturpr-t ively/interuptive Iy if no source file was named), with 

"reasonable" Defaults in effect. Note thaT this all is meant to 

i mo I y mat "native" commanus are not directly invokable from the 
U( duP environment (otter than by "call"), to avoid potential 

naming conflicts between system commands and new UULP commanus. 
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° n th '“ 1j P‘ c I o ? j o i m j out, the JULP command is "lo-joul" 

laobrisvution: out). The Server must close the Tilr.et connection 
after Jnny whatever is appropriate to '3 f f t> c t a logout. To 
rcToin tno Telnet connection, "logout -save". Having the Server 
close xs vieweaos a convenience for the user, in that it spares 
nA:l1 rn - necssity jf causing nis User Telnet to close. (It is 
assumeJ to be no hardship on Servers to step beyond the atavistic 
position that anybody who legs in to then is at a hardwired local 


terminal. ) 


anybody who legs in 


Finally, a comment seems to be in order on error messages. Some 
explicit messages nav>. oeen legislated herein. Many areas nave 
not been oeolt with, though. It is the spirit of the UULP -that 
error messages should oe composed in full awareness of the 
difference between conciseness and terseness, and should err, if 
necessary, on the side of o v e r-e xp I a i r. i rg ratner than 
under-exp laming. Another way of putting it is that "CAN'T" is 
an error message wnicn violates the spirit of the UULP (and the 
sensibilities of its propounder). 


APPENDIX 1. THE COMMON COMMAND SUBSET 


S ynta x 


Ab br 


I. "Set-up" Commands 

'login i.d axil in 

The j.d may oe Network-wide or Host-speci f ic . 
"■♦free" is reserved. 

The aca may be "-mail", "-who", "-concom", 
or may be absent. 

Result is to be either logged in or passed 
off to appropriate daemon. 

prompt chan pr 

Specifies that is to become or 

preceue the normal prompt message. 

Acceptable prior to login. 

t 

erase cnajr x 

Specifies fnat £,tia£ Is the erase character. 
Invocation with no argument reverts to default. 

Hill £LUC X 

Specifies that cQar is the Kill character. 
Invocation with no argument reverts to default. 
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a u I X 

Specifies tneT Chur is the mop I in*; clurPctcr. 
Invocation with no aryuinenf ru-varts to aefault. 

local Ioc 

Enter The local command environment . 

f t o 

Enter the -TP environment. 


r J e 

Enter the ^JE environment. 

logout out 

Logout and sever the Telnet connection. 

lojout -Save out 

Logout but K^ep the Telnet connection. 


Apply the lose-,mapping conventions of Appendix 2* 
Required on Hosts to which case is significant. 


II. Communications Commands 

rooQinai I rm 

Type out “mailbox". 

readinail (la) -at £25.1 rm X 

Type out "mailbox" on remote Host hos.t. 
Multiple Hosts may be specified* 
separated oy spaces (blanks). 

Implies aoiliry to change working directory 
at host to directory implied by known 
user identifier, or (optionally) by id. 

readmaiI -a I I rm XX 

Search for mail. 

Extremely optional,. 

maiI id 

Collect inout until line consisting of 
only a period (".") for mailing to local 
user specified by 12. 

mail - f f_i.io id 

Send contents of specified file to specified 
local user. 

mail 12 -at Q 2 S .1 

Collect inout until line consisting of 
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only o peri o j for' muilinj to remote 

uptrlpl al specified lio: t (i) . doth _i,.£ and 
bPliJL may Pi multiple, seppratcJ oy spaces. 

(If multiple, they shuula be Taken pairwise.) 

mbi I -f ij.J.p: i.b -at pgst_ 

Sena conun rs of specified file to specified 
remote use' (s) . 


who 


The generic who's logged in command. 


who ^a 

Is id lagged in? Constrained responses, 
who id -ot hns r 

Is the specified user loggea in at the 
specified tost. Constrained responses. 

concom -on cc 

Enable console to console communications. 


concom 


off cc 

Disable console to console communications. 


concom i_a cc 

Sena messages to specified local user 
until line consisting of only a period 


) . 


concom ig. 


“at hOS t 

Send messages to 


specified 


cc 

remof a 


user. 


III. File Commands 

type £At.h ppL/itr 

Type out tne contents of the specified file. 
Pathname may be local or Network-wide. 

Default to current working directory. 

I i s t dir Id 

List the contents of the current working directory. 
(Local fornaT acceptable.) 


I i st d ir £.vt h 

List the contents of 

rename gld new 

Change the specified 

a ad name oJ_c new 

Give tne soecified f 


1 he 

1 d 

specified 

directory. 


rn 


f i 1 

c*s name as 

indicated. 


an 

X 

1 e 

the specifi 

ed extra name 
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delete j-ili re*W«- d l 

G <_ t ciu of rfu- s pucifi-3'J f i I vi. 

("Expun;j£" if n e c e s s ar y . ) 

coov j_u2!H is 

MaKc l copy of tnu file specified o y fhi first pathname 
ci t the second pa thru me. 

li.iK lc.2!ii Is X 

If your file system has such a concept, me.Ke a "linK" 
biitniun tne two pathnames. If no stcona argument, 
use same entry name in worKing directory. 


status o aih st X 

If your file system has such a concept, give status 
information UDout the specified file or directory. 


c w J i> a2ll 
pwd 

edit n-Itl 


X 

If no argument, return to the "home" directory. 

X • 

Type out tne pathname of the current worKing directory. 

X 

See Apponaix 3. 


IV. Invoicing "Native" Programs 

call name ( ar a s) exccut£- 

InvoKtd the specified program with the 
specified arguments (if any). 

. The following names are reserved to indicate the 

invocation of tne corresponding languc^ge processors 
"-pll", "-oasic", "-fortran", "-lisp". 

(If no sou-ce file indicated, invoke "interpretively" 
if possible.) 

V. On-line Documentation 

help no j, u ? 

Type-cut information aoout tne specified UULP command. 
If name is ”-sys", type out information about now to 
use Thu local system's nelp mechanism? if 
"-uu Ip", uoouf the local system's UULP implementation. 
If no name given, jescriov tne command itself. 



Al-'Pi. NJ Ia 2 . map COW HAND 


CUN N/tN T IONS 


^ h * s a u p o n o i x iv x I ! 

conventions Jxloi ' 


uu x n 


eventual 
RFC wii. 


contain 


T h Xr 


c ase - 


capping 


APPlMJIX 3. EDIT COMMAND REQUESTS 


This jjpenaix 
command request 


will 
; (to 


fiventua I I y contain 


o» nfu,, descriptions of the edit 

now, jt should oe sufficxcU t T * US 

° ; !!«?’ to »’ ^ 0 , save,and quit - 

0 ‘^ohionc-a flavor of context 


t he 


edit or. 


request: 

i * e • « 


For 
are 
it • s 


Note.* doth 
full w n e n I 
Da Ix gntIy 
neither case 
over a I | tasK d f 
course be important 


Apoenoix 2 ana Appendix 3 will be suani;*»H • 

*»r.„ 8 , h to 00 so! S B0°?h tl M 
euxted versions of existing boucument- I 

P5rtiCJ,ar,y * niport ant to’ the 
c x yxng a UULP, although they will of 
implementing one. 0 T 


t o 



